Topic

• 在Kafka中，每筆資料都是事件(Event)，而 Topic 就是這些事件的儲存空間。
• 你可以大致將Topic理解為資料庫中的Table，而Event則類似於資料表中的Record 或 Row。
• 需要特別注意的是，Topic是一種Log的檔案結構，而不是資料結構中的Queue。也就是說，當資料被讀取(消費）後，並不會像Queue一樣自動刪除。Kafka 允許你設定 Retention Policy，透過設置時間或大小限制，來控制資料的保留期限。

Topic的Log 結構

• Topic是一種"Append-Only"的Log，所有事件都只能新增在Topic結構的最尾部，無法在中間插入任何資料。
• 當 Producer 傳送 Event 到某個 Topic 時，該事件會從前一筆事件的後面繼續寫入下一個事件。

Topic可分割為多個 Partition

• 每個Topic 可以分為多個Partition，這些Partition即存放Event的位置，可以分散在Kafka集群中的不同節點（Broker，例如多個實體機器)上。這種分散儲存方式提高了可用性和效能。

• Kafka 的每個 Partition 可以被分配到不同的 Broker，並且每個 Partition 可以獨立處理 Producer 和Consumer的讀寫，這關係著:

  • Producer的效能提升
    • Producer可以同時將資料發送到不同的Partition上，增加了併發寫入的效能。當Partition增多時，Producer可以平行處理更多的請求。
  • Consumer的效能提升
    • Consumer可以平行消費不同Partition中的資料。當有多個Consumer組成 Consumer Group 時，Kafka會自動將Partition分配給各個Consumer，讓他們並行處理。

Event只能透過Offset讀取

• 在Kafka中，每個 Partition 中的 Event 都有一個唯一的 Offset，也就是從第0位開始的偏移量
• 要讀取Event，必須先指定Offset，而不是指定索引值(index)來取值(Can only be seek by offset, not indexed)。
• 例如: 假設Consumer上一次消費了某個Partition中，Offset 2的Event，下次消費時將會從Offset 3開始。
  

Producer

• Producer是負責將Event傳送到Topic的角色。而前面我們提到，Topic會有多個Partition。那麼，如何決定要把Event寫入哪個 Partition 呢？ 會根據有無指定Event Key來決定:

無指定 Event Key 的情況

• 如果Producer沒有指定Event的Key，Kafka會採用輪詢機制(Round Robin)，將事件依次寫入不同的 Partition。
• 例如，第一次寫入Partition 0，下一次寫入Partition 1，依此類推。
• 這種方式適合不需要關注事件順序的場景。

有指定 Event Key 的情況

• 當Producer有指定Event Key時，Kafka會保證擁有相同Key的事件都被寫入同一個Partition，並依序寫入，也就是在同一個Partition一直Append event上去。
• Kafka預設會用雜湊函數算出Event key的雜湊值，再用這個值去Mod Partition的數目。這個結果就是要寫入的Partition Id
• 這個機制確保了事件的順序性，適合需要維護讀取順序的場景，例如：當希望某個客戶的Event都寫入同一個 Partition時，可以用這個客戶的Customer Id當Event Key，確保資料的順序性。

Event Key 的潛在問題

使用Event Key雖然保證了順序性，但如果某個 Event Key非常活躍（如一個頻繁產生資料的客戶)，可能會導致某一個Partition特別大，造成資料不平均分佈在不同的Partition上。

結論

• Kafka的Topic以Log結構儲存事件，並透過Partition分散數據，這使得它在處理資料量大的數據流時，具有著較高的效能與彈性。而 Producer在寫入事件時，可以選擇是否指定Event Key，根據不同場景的需求來決定事件的分佈和順序。

下一章將繼續介紹Consumer在消費Event時的詳細機制。